REMARKS/ARGUMENTS 

Claims 5-11, 16-22 and 27-36 are pending in the present application. Claims 5, 11, 16, 
22, 27 and 33 have been amended, and Claims 34-36 have been added, herewith. The listing of 
the claims beginning on page 2 of this response replaces all prior versions, and listings, of claims 
in the application. 

Applicants are not conceding in this application the subject matter removed from 
amended claims and/or in canceled claims are not patentable over the art cited by the Examiner. 
The present claim amendments and cancellations are only for facilitating expeditious prosecution 
of the application. Applicants respectfully reserve the right to pursue these and other claims in 
one or more continuations and/or divisional patent applications. 

I. 35 U.S.C. § 103. Obviousness 

Claims 5-11, 16-22 and 27-33 stand rejected under 35 U.S.C. § 103(a) as being 
anticipated by Callahan, E et al. (U.S. Patent No. 2002/0129339), hereinafter "Callahan" in 
further view of Krishnaiyer et al. (U.S. Patent No. 2004/0123041), hereinafter "Krishnaiyer". 
This rejection is respectfully traversed. 

The Examiner bears the burden of establishing a prima facie case of obviousness based 
on prior art when rejecting claims under 35 U.S.C. § 103(a). In re Fritch, 972 F.2d 1260, 23 
USPQ2d 1780 (Fed. Cir. 1992). In re Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 
(Fed. Cir. 1992). Only if that burden is met, does the burden of coming forward with evidence or 
argument shift to the applicant. Id. All words in a claim must be considered in judging the 
patentability of that claim against the prior art. MPEP 2143.03; In re Wilson, 424 F.2d 1382, 
1385, 165 USPQ 494, 496 (CCPA 1970). If the Examiner fails to establish a prima facie case, 
the rejection is improper and will be overturned. In re Fine, 837 F.2d 1071, 1074, 5 USPQ2d 
1596, 1598 (Fed. Cir. 1988). In the absence of a proper prima facie case of obviousness, an 
applicant who complies with the other statutory requirements is entitled to a patent. See In re 
Oetiker, 911 F.2d 1443, 1445, 24 USPQ2d 1443, 1444 (Fed. Cir. 1992). 

With respect to Claim 5, Applicants have amended such claim to clarify that the 
'indicators': (1) specify counting of events that are associated with execution of the instructions 
or (2) specify counting of events that are associated with accesses to memory locations. In 
addition, per the features expressly recited in Claim 5, the indicators specify the counting of 
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events on a 'per instruction' or a 'per memory location' basis such that only the events specified 
by the indicators are counted. In contrast, per the teachings of the primary reference to Callahan, 
trace information is generated by compiling target source code in such a manner that executing 
the resulting executable code will generate execution trace information composed of a series of 
events, where each event stores trace information related to a variety of performance measures 
(Callahan paragraph 0040, lines 6-12). To the extent the Callahan 'instructions' are deemed as 
being equivalent to the claimed 'indicators', they are in fact not equivalent to one another since 
the Callahan executable instructions do not specify the counting of events on a 'per instruction' 
or a 'per memory location' basis such that only the events specified by the indicators are 
counted, as claimed. 

Specifically with respect to Claim 5, such claim recites "generating, by the compiler, 
indicators to be processed by the processor during execution of the instructions, wherein the 
indicators are data values that are retrieved from memory during execution of the instructions 
and specify counting of events that are associated with execution of the instructions or are data 
values that are retrieved from memory during execution of the instructions and specify counting 
of events that are associated with accesses to memory locations, and wherein the indicators 
specify counting of events on a per instruction or a per memory location basis such that only the 
events specified by the indicators are counted to form the performance information". As can be 
seen, the claimed indicators: (1) specify counting of events that are associated with execution of 
the instructions or (2) specify counting of events that are associated with accesses to memory 
locations; and (3) specify the counting of events on a 'per instruction' or a 'per memory location' 
basis such that only the events specified by the indicators are counted. 

In rejecting this aspect of Claim 5, the Examiner alleges that Callahan teaches all such 
aspects of Claim 5 at paragraphs 0040, 0062 and 0082-0103. Applicants show that there, 
Callahan states: 

[0040] Some embodiments of the present invention provide a method and system for conducting 
performance analysis for task execution. The analysis involves generating a variety of trace 
information related to performance measures, including parallelism-related information, during 
execution of the task. In order to generate the trace information, target source code of interest is 
compiled in such a manner that executing the resulting executable code wiU generate execution 
trace information composed of a series of events. Each event stores trace information related to a 
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variety of performance measures for the one or more processors and protection domains used. 
After the execution trace information has been generated, the system can use that trace 
information and a trace information description file to produce useful performance measure 
information. The trace information description file contains information that describes the types 
of execution events as well as the structure of the stored information. The system uses the trace 
information description file to organize the information in the trace information file, extracts a 
variety of types of performance measure information from the organized trace information, and 
formats the extracted information for display. The system can use default or user-defined 
functions to extract and format trace information for display. After the system displays one or 
more types of performance measure information, a user of the system can then interact with the 
system in a variety of ways to obtain oilier useful pciiormance analysis information. 
[0062] After receiving the source code and any compiling instructions, the compiler generates the 
traceable executable code file 224 stored on the permanent storage. In the illustrated embodiment, 
the various sample points are implemented by having the compiler add appropriate instructions to 
the source code at each sample point location before the source code is compiled. When executed, 
these added instructions will determine the hardware-related and software-related values of 
interest, and will write an event containing those values to an execution trace information file. 
Thus, each event in the execution trace information file wiU be of a specified type that 
corresponds to the sample point that creates the event. As described previously, in the illustrated 
embodiment a trace information description file describes the types of execution events and their 
corresponding structure. Those skilled in the art will appreciate that in some embodiments the 
definitions of the events from the trace information description file merely reflect pre-defined 
event types that are provided by the compiler, while in other embodiments the compiler can use 
the information in the trace information description file to define the possible event types and to 
determine the appropriate instructions to be added to generate such events. 
[0082] In addition to the four pre-specified counters, each protection domain state also includes 
four selectable event counters 325-328. Each of the selectable event counters can be specified to 
count one of a variety of types of hardware events. In the illustrated embodiment the selectable 
events including the following: 

[0083] the number of operations executed by the m-unit 
[0084] the number of operations executed by the a-unit 
[0085] the number of operations executed by the c-unit 
[0086] the number of set operations for the target registers 
[0087] the number of load operations issued 
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[0088] the number of store operations issued 

[0089] the number of int_fetch_add operations issued 

[0090] the number of memory operations retried, including forwarding 

[0091] the number of float_add and fIoat_sub operations 

[0092] the number of float_add_muI operations 

[0093] the number of float_div operations 

[0094] the number of float_sqrt operations 

[0095] the total number of floating-point operations 

[0096] the number of expected jump or skip paths taken 

[0097] the number of unexpected jump or skip paths taken 

[0098] the sum of all transfer operations 

[0099] the number of level enter operations 

[0100] the number of traps taken 

[0101] the number of stream_create operations, and 

[0102] the number of stream quit operations. 

[0103] In the illustrated embodiment, each of the eight counters are updated only periodically, 
such as every 256 cycles. Thus, for example, every 256 cycles the instruction issue counter wiU 
be incremented by the number of instructions that had issued in the domain since the previous 
update, thereby providing a total count of the number of instructions that have issued since some 
starting point such as when the processor was last booted. The other counters are updated in a 
similar manner. Thus, instructions added to the traceable executable code can retrieve and 
provide information stored in any or aU of the counters for the processor state, the stream states, 
and the protection domain states. 

Cited paragraph 0040 of Callahan is the Summary of the Invention, and describes at a 
high level an ability to conduct performance analysis for task execution, where a variety of trace 
information related to performance measures are generated during execution of a task. In order 
to generate the trace information, 'target source code' of interest is compiled in such a manner 
that executing the resulting executable code will generate execution trace information composed 
of a series of events that each stores trace information related to a variety of performance 
measures. Various post-execution processes are also described. This cited passage does not 
describe compiler-generated indicators that specify the counting of events on a 'per instruction' 
or a 'per memory location' basis such that only the events specified by the indicators are 



Page 11 of 18 
DeWitt, Jr. et al. - 10/682,385 



counted, as claimed. Instead, code is executed to generate a series of events that can be 
subsequently analyzed. 

At paragraph 0062, Callahan describes that a compiler adds 'instructions' at each 'sample 
point' in the source code before the source code is compiled. These instructions that are added to 
the source code and compiled will provide a tracing functionality when executed. Specifically, 
when these added instructions are executed, events of interest are determined (Callahan 
paragraph 0062, lines 7-13). It is urged that neither the Callahan 'sample points' nor the 
'instructions' are equivalent to the claimed 'indicators' since they do not specify the counting of 
events on a 'per instruction' or a 'per memory location' basis such that only the events specified 
by the indicators are counted, as claimed. 

As to the cited passage at paragraphs 0082-0102, there Callahan describes a list of 
'events' that can be counted. This cited passage does not describe any characteristics pertaining 
to 'indicators' that are generated by a compiler, and therefore this cited passage cannot describe 
particular characteristics/features of the compiler-generated 'indicators' that are expressly recited 
in Claim 5. 

Finally, as to the cited passage at paragraph 0103, there Callahan describes that the 
'counters' are updated 'periodically'. Such periodic updating of counters does not describe 
characteristics/features of 'indicators' that are generated by a compiler, but instead describe 
characteristics/features of hardware counters - and such hardware counters are not generated by 
a compiler, as are the claimed 'indicators'. 

Thus, it is urged that Claim 5 has been erroneously rejected due to the above described 
prima facie obviousness deficiencies pertaining to the claimed compiler-generated 'indicators'. 

Applicants initially urge error in the rejection of Claims 6-11 for reasons given above 
with respect to Claim 5 (of which Claims 6-11 depend upon). 

Further with respect to Claim 7 (and dependent Claims 8 and 9), such claim recites 
"determining, by the compiler, alternative ways to compile the source code statements; 
compiling the source code statements in multiple ways to generate multiple sets of instructions 
for the compiled source code statements; and placing each set of instructions in a different 
execution path to be selected based on the count value". Claim 7 is directed to compiler-based 
actions. Specifically, alternate ways to compile the source code statements are determined by a 
compiler. The source code statements are compiled in multiple ways to generate multiple sets of 
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instructions for the compiled source code statements. Each such set of instractions is placed in a 
different execution path to be selected based on the count value. 

The Examiner alleges that Kiishnaiyer teaches all aspects of Claim 7 at paragraphs 0011 
and 0020. Applicants show that there, Kiishnaiyer states: 

[001 1] In an embodiment of the invention, the computer program product, e.g., the compiler, may 
determine during compilation of the source code 1) if the loop is accessed a sufficient number of 
times to achieve a performance gain from active prefetching; and 2) if an irregular load exists in 
the loop. In this embodiment of the invention, the computer program product may generate code 
to determine dj^amically, i.e., during execution of the output code, whether the irregular load has 
a predictable access pattern. The computer program product may also insert a prefetch instruction 
into the output code, the prefetch instruction only being executed if certain conditions are met. 
This may be referred to as insertion of conditional adaptive prefetch code including a conditional 
prefetch instruction. If the computer program product determines statically that the loop was 
accessed a sufficient number of times and that an irregular load exists in the loop, and the 
generated code identifies that the irregular load has a predictable access pattern, then the 
conditional prefetch instruction in the inserted conditional adaptive prefetch code may be 
executed. 

[0020] Alternatively, the loop count module of the computer program product, e.g., compiler, 
may insert loop counting code into the output code, where the loop counting code determines the 
number of times the loop may be accessed during the execution of the output code by counting 
the number of times the loop is accessed. If the loop counting code determines the number of 
times the loop may be accessed is greater than the threshold value, the inserted conditional 
adaptive prefetching code may be executed during output code execution. 

At paragraph 001 1, Krishnaiyer describes that a compiler analyzes code that is being compiled to 
determine (i) if a loop is accessed a certain number of times (to achieve a performance gain by 

using prefetching), and (ii) if an irregular load exists in the loop. This cited passage also 
describes that the compiler may generate specialized access-pattem-prediction code to 
dynamically determine during runtime whether the irregular load has a predictable access 
pattern. The compiler may also insert specialized prefetch code into the output code, where such 
inserted prefetch code is conditionally executed based on certain conditions being met when the 
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code is dynamically executing. This cited passage also describes certain runtime processing 
features which are not germane to the compiler-based actions that are recited in Claim 7. 

Thus, this paragraph 00 11 describes a compiler (i) generating specialized access-pattem- 
prediction code, and (ii) inserting prefetch instructions into the output code. It is urged that 
neither the generating of new code nor the inserting of prefetch instructions into output code 
describes compiler-actions pertaining to compiling of the same source code statements in 
multiple ways to generate multiple sets of instructions for the compiled source statements. 
Instead, this cited passage describes that new code is added to existing code and compiled. 

At paragraph 0020, Krishnaiyer describes inserting special loop counting code into the 
output code. It is urged that the inserting of loop counting code into output code does not 
describe compiler-actions pertaining to compiling of the same source code statements in multiple 
ways to generate multiple sets of instructions for the compiled source statements. Instead, this 
cited passage describes that new code is inserted into output code. 

Thus, it is further urged that Claim 7 (and dependent Claims 8 and 9) has been 
erroneously rejected due to such prima facie obviousness deficiencies. 

Further with respect to Claim 8 (and dependent Claim 9), such claim recites "identifying 
a compiler directive among the source code statements that specifies a type of autonomic 
monitoring to be implemented by the compiler; and identifying alternative ways to compile the 
source code statements based on the compiler directive". Per Claim 8, a 'compiler directive' ^ 
among the source code statements is identified that specifies a type of autonomic monitoring to 
be implemented by the compiler. In addition, alternative ways to actually compile the source 
code statements are identified based on such identified 'compiler directive' . 

The Examiner alleges that Krishnaiyer teaches all such compiler-directive aspects of 
Claim 8 at paragraphs 0014 and 0020. Paragraph 0020 has already been reproduced and 
characterized above, and describes inserting loop counting code into output code. This cited 
passage does not describe characteristics/features of a 'compiler directive', as claimed. As to 
cited paragraph 0014, there Krishnaiyer states: 



^ Compiler directive - 1. A language construction for the purpose of controlling the compilation of a program. 2. A 
statement that controls what the compiler does rather than what the user program does. Synonymous with compiler 
directing statement (Source: IBM Dictionary of Computing, Eighth Edition, March 1987, Copyright International 
Business Machines Corporation 1987, PubUcation No. SC20-1699-7). 
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[0014] In an embodiment of the present invention, a prefetch insertion module in a computer 
program product may insert conditional adaptive prefetch code into the output code. In this 
embodiment, an irregular load pattern determination module in a computer program product, e.g., 
a compiler, may insert pattern recognition code into the output code to calculate whether 
successive iterations of an irregular memory load in a loop have a predictable access pattern. If 
successive iterations of the irregular memory load have the predictable access pattern, the 
conditional prefetch instruction in the conditional adaptive prefetch code inserted into the output 
code may be executed and the irregular memory load corresponding to at least one future iteration 
of the loop may be retrieved. In this embodiment, if the predictable access pattern is not found 
when the program is run and the loop executed, the conditional prefetch instruction in the inserted 
conditional adaptive prefetching code may not be executed. 

Here, Krishnaiyer describes a compiler module that 'inserts' prefetch code into output code, and 
another compiler module that 'inserts' pattern recognition code into the output code. Various 
runtime characteristics are also described that are not germane to the compiler-processing aspects 
of Claim 8. It is urged that neither the insertion of prefetch code nor the insertion of pattern 
recognition code into output code by a prefetch instruction module and an irregular load pattern 
determination module, respectively, describes any characteristics pertaining to an actual 
'compiler directive' that is among the source code statements, as is provided by the features of 
Claim 8. Instead, executable portions of the compiler itself are described as inserting code into 
output code. 

In addition, such code insertion into output code does not describe identifying alternative 

ways to compile the same source code statements, as is provided by the 'compiler directive' 
features of Claim 8. Instead, new/additional code is described as being 'inserted' into output 
code. 

Thus, it is further urged that Claim 8 (and dependent Claim 9) has been erroneously 
rejected due to such prima facie obviousness deficiencies. 

Further with respect to Claim 9, such claim recites "specifying an event in the compiler 
directive to be autonomically monitored". Claim 9 is also directed to characteristics/features of a 
'compiler directive' . Specifically, such 'compiler directive' specifies an event to be 
autonomically monitored. 
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The Examiner alleges that Krishnaiyer teaches all aspects of Claim 9 at paragraphs 0014 
and 0020. The cited passages have already been reproduced and characterized above, and 
describe a compiler inserting new code into output code. It is urged that the insertion of new 
code into output code by a compiler does not describe characteristics/features of an actual 
'compiler directive', as is provided by the features of Claim 9 (per Claim 9 - "specifying an 
event in the compiler directive to be autonomically monitored"). Thus, it is further urged that 
Claim 9 has been erroneously rejected due to such additional prima facie obviousness 
deficiencies. 

Further with respect to Claim 10, such claim recites "determining, by the compiler, 
alternative ways to compile a subroutine within the source code statements; generating a 
plurality of compiled versions of the subroutine, wherein each compiled version has been 
compiled differently from other compiled versions of the subroutine; and placing the plurality of 
compiled versions of the subroutine in different execution paths to be selected based on the count 
value". Per Claim 10, the compiler determines alternative ways to compile a given subroutine. 
A plurality of compiled versions of this same subroutine are generated. 

The Examiner cites the identical passages of Kiishnaiyer that were used in rejecting 
Claim 7 in the rejection of Claim 1 0. For similar reasons to those given above with respect to 
Claim 7, these cited Krishnaiyer passages describe that new code is inserted into output code. It 
is urged that the inserting of new code into output code does not describe compiler-actions 
pertaining to compiling of the same subroutine in multiple ways to generate a plurality of 
compiled versions of the same subroutine. Thus, it is further urged that Claim 10 has been 
erroneously rejected due to such prima facie obviousness deficiencies. 

Further with respect to Claim 11, such claim recites processing, by the compiler, at least 
one compiler directive that specifies to the compiler the selection of the execution path. Claim 
1 1 is also directed to characteristics/features pertaining to a 'compiler directive'. Specifically, 
the 'compiler directive' of such claim specifies the selection of the execution path. 

The Examiner alleges that Krishnaiyer teaches all aspects of Claim 1 1 at paragraphs 14 
and 20. These cites passages have already been reproduced and characterized above, and 
describe insertion of new code into output code. It is urged that neither the insertion of prefetch 
code nor the insertion of pattern recognition code into output code by a prefetch instruction 
module and an irregular load pattern determination module, respectively, describes any 
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characteristics pertaining to an actual 'compiler directive', as is provided by the features of 
Claim 1 1 . Instead, executable portions of the compiler itself are described as inserting code into 
output code. Thus, it is further urged that Claim 1 1 has been erroneously rejected due to such 
additional prima facie obviousness deficiencies. 

Applicants initially traverse the rejection of Claims 16-22 and 27-33 for similar reasons 
to those given above with respect to Claim 5. 

Applicants further traverse the rejection of Claims 17 and 28 for similar reasons to the 
further reasons given above with respect to Claim 6. 

Applicants further traverse the rejection of Claims 18 and 29 for similar reasons to the 
further reasons given above with respect to Claim 7. 

Applicants further traverse the rejection of Claims 19 and 30 for similar reasons to the 
further reasons given above with respect to Claim 8. 

Applicants further traverse the rejection of Claims 20 and 31 for similar reasons to the 
further reasons given above with respect to Claim 9. 

Applicants further traverse the rejection of Claims 21 and 32 for similar reasons to the 
further reasons given above with respect to Claim 10. 

Applicants further traverse the rejection of Claims 22 and 33 for similar reasons to the 
further reasons given above with respect to Claim 1 1. 

Therefore, the rejection of Claims 5-11, 16-22 and 27-33 under 35 U.S.C. § 103(a) has 
been overcome. 

II. Newly Added Claims 

Claims 34-36 have been added herewith. Examination of such claims is respectfully 
requested. 
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It is respectfully urged that the subject application is patentable over the cited references 
and is now in condition for allowance. The Examiner is invited to call the undersigned at the 
below-listed telephone number if in the opinion of the Examiner such a telephone conference 
would expedite or aid the prosecution and examination of this application. 



DATE: December 30. 2011 

Respectfully submitted, 



AVavne P. Bailey/ 



Wayne P. Bailey 
Reg. No. 34,289 
Yee & Associates, P.C. 
P.O. Box 802333 
Dallas, TX 75380 
(972) 385-8777 
Attorney for Applicants 
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